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ABSTRACT 



Interoperability is facilitated between two networks. One 
method according to the present invention comprises: pro- 
viding a VHN network having a VHN element; providing a 
HAVi network having a HAVi element; t ranslating messag es 
^a a protocol translator c oupled wit h the VHN ne t worka nd 
the HAVi network; wherem interoperability is facilitated 
between the HAVi element and the VHN element. 



500 



502 

\ 










VHN 










Network 














^508 


504 

/ 










HAVi 








506 


Network 





















03/15/2004, EAST Version: 1.4.1 



Patent Application Publication Nov. 29, 2001 Sheet 1 of 8 



US 2001/0047431 Al 





FIG.1 



212 



I/O 

CONTROLLER 



214 



SYSTEM 
MEMORY 



1 



218 



DISPLAY 
ADAPTER 



104 



MONITOR 



_L 



216 



CENTRAL 
PROCESSOR 



220 

J. 



SERIAL 
PORT 



108 

J. 



RPD 



210 

z_ 



JL 



106 

.7-. 

230 



TRANSCEIVER 



222 



224 



FIXED 




NETWORK 


DISK 




INTERFACE 



112 



KEYBD 



234' 



236 



LOCAL 
NETWORK 



FIG. 2 



TO 
INTERNET 



03/15/2004, EAST Version: 1.4.1 



Patent Application Publication Nov. 29, 2001 Sheet 2 of 8 



US 2001/0047431 Al 




03/15/2004, EAST Version: 1.4.1 



Patent Application PubUcation Nov. 29, 2001 Sheet 4 of 8 US 2001/0047431 Al 



o 
in 



o 



o 

I 

I 

X 



O. 

o 

CO 

















LU 















1 








1 


HAVi 
DVD 
DCM 




IP 


HAVi 
. _ - msgs 


C\J 






CO 








2 IS 












HAVi 
HDD 
DCM 






HAVi' 

menc 


CM 


X X 




CO 



a> 

CO 

LU 
LU 




> 



CO 

O 
CO 



Q 
O 
X 



CO 
CO 



.CO 
o 



CO 

o 

LL 



03/15/2004, EAST Version: 1.4.1 



Patent Application PubUcation Nov. 29, 2001 Sheet 3 of 8 US 2001/0047431 Al 



Trigger 



400 

__V, 



(A) 
Controller 
Application 
Component 



Interface Transfer 



Communication Message 
with Vocabulary 



402 

/ 

(B) 

Controlled Module 
Application Interface 



(C) 

Controlled Application 
Component 



■408 
■406 




'>404 



FIG. 4 




500 




FIG. 5 



03/15/2004, EAST Version: 1.4.1 



Patent Application PubUcation Nov. 29, 2001 Sheet 5 of 8 



US 2001/0047431 Al 



Device plugged 
into HAVi network 

S700 



User causes HNB 
& IR to be read 
and finds device to 
control 

S800 



VBCM is notified 
S702 



User inputs 
command to 
control device 

S802 



VBCM instantiates 
HAVi-VHN device 
DCM 

S704 



Command 
encoded in XML 
and sent to VBCM 

S804 



HAVi DCM 
manager loads 
HAVi device DCM 

S706 



HTML/XML 
command sent to 
HAVi-VHN device 
DCM 

S806 



Device registered 
in HNB & IR 

S708 



HG.7 



HAVI-VHN device 
DCM encodes 

command into HAVi 
messaging and 
controls device 

S808 



FIG. 8 



03/15/2004, EAST Version: 1.4.1 



Patent Application Publication Nov. 29, 2001 Sheet 6 of 8 



US 2001/0047431 Al 



VHN application queries 
HNB&IR 


S900 








VHN application 
discovers HAVi 






application 






S902 




1 






VIHN application 
sends XML RPC 






to HAVi application 






S904 










VHN XML message 
translated into 






a HAVi message 






S9Q6 






• 




VHN BCM sends 






HAVi message to 
HAVi application 
viaHAVi-VHN DCM 






S908 





FIG. 9 



VHN device queries 
HNB&IR 

S1000 




r 




VHN device sends 
XML message to 
VHN BCM 

S1002 










VHN BCM reformats 
XML message into 
HAVi message 

S1004 






r 




HAVi DCM sends 
HAVi message to 
VHN BCM 

S1006 










VHN BCM translates 
HAVi message into 

XML message that is 
sent to VHN device 

S1008 





FIG. 10 



03/15/2004, EAST Version: 1.4.1 



Patent Application PubUcation Nov. 29, 2001 Sheet 7 of 8 US 2001/0047431 Al 



VBCM discovers device on 
VHN network 

S1100 



VBCM creates VHN 
Dm 

S1102 



VHN DCI\/I registers witli 
registry 

S1104 



I 



HAVi application queries and 
finds device to control on VHN 
networl< 

S1 106 



HAVI application sends 
command to VHN DCM via 
HAVi messaging 

S1108 



VHN DCM communicates witli 
VBCM via XML/HTML 

S1110 



VBCM communicates with 
VBCM via XML 

S1112 



I. 



HBCM controls 
device 

S1114 



HAVi application queries 
HAVi registry 

S1200 



HAVi application sends 
messages to HAVi-VHN 
DCM 

S1202 



VHN HAVi-VHN DCM 
translates HAVi message to 
XML 

S1204 



VHN BCM translates the 
XML to HAVi and sends to 
HAVi application 

SI 206 



FIG. 12 



FIG. 11 



03/15/2004, EAST Version: 1.4.1 



Patent Application PubUcation Nov. 29, 2001 Sheet 8 of 8 US 2001/0047431 Al 



HAVi device sends 
message to VHN device 

S1300 



VHN device's HAVi-VHN 
DCM translates HAVi to XIVIL 
message 

SI 302 



HAVi device gets SEID from HAVi 
reglstiy & sends message 

S1400 



VHN device sends 
XML response 

S1304 



VHN application sends HAVi 
message to VHN BCM 

S1402 



VHN BCM translates 
XML to HAVi via 
HAVi-VHN DCM 

SI 306 



VHN DCM sends XML message 
to VHN application 

S1404 



VHN BCM sends HAVi 
message to HAVi DCM 

S1308 



FIG. 13 



FIG. 14 



03/15/2004, EAST version: 1.4.1 



us 2001/0047431 Al 



1 



Nov. 29, 2001 



HAVI-VHN BRIDGE SOLUTION 

CROSS-REFERENCES TO RELATED 
APPLICATIONS 

[0001] This invention derives priority from U.S. Provi- 
sional Patent Application No. 60/181,406, filed Feb. 9, 2000 
and entitled "HAVi-VHN Bridge Solution," which is incor- 
porated herein in its entirety for all purposes. 

BACKGROUND OF THE INVENTION 

[0002] A typical home audio/video (AV) equipment set-up 
includes a number of components. For example, a radio 
receiver, a compact disc (CD) player, a pair of speakers, a 
television (TV), a video cassette recorder (VCR), a tape 
deck and the like. Each of these components are connected 
to each other via a set of wires. One component is usually 
the central component of the home AV system. This is 
usually the radio receiver or the tuner of the radio receiver. 
The tuner has a number of specific inputs for coupling the 
other components. The tuner has a corresponding number of 
control buttons or control switches which provide a limited 
degree of controllability and interoperability for the com- 
ponents. The control buttons and control switches are usu- 
ally located on the front of the tuner. In many cases, some 
or all of these buttons and switches are duplicated on a 
hand-held remote control unit. A user controls the home AV 
system by manipulating the buttons and switches on the 
front of the tuner, or alternatively, manipulating buttons on 
the hand-held remote control unit. 

[0003] This conventional home AV system paradigm has 
become quite popular. As consumer electronic (CE) devices 
become more capable and more complex, the demand for the 
latest and most capable devices has increased. As new 
devices emerge and become popular, the devices are pur- 
chased by consumers and "plugged" into their home AV 
systems. Generally, the latest and most sophisticated of these 
devices are quite expensive (e.g., digital audio tape record- 
ers, digital video disc (DVD) players, digital camcorders and 
the like). As a consumer purchases new devices, most often, 
the new device is simply plugged into the system alongside 
the pre-existing, older devices (e.g., cassette tape deck, CD 
player and the like). The new device is plugged into an open 
input on the back of the tuner, or some other device coupled 
with the tuner. The consumer (e.g., the user) controls the 
new device via the control buttons on the tuner, via the 
control buttons and control switches on the front of the new 
device itself, or via an entirely new, separate, respective 
remote control unit for the new device. 

[0004] As the number of new CE devices for the home AV 
system has grown and as the sophistication and capabilities 
of these devices have increased, a number of problems with 
the conventional paradigm have emerged. One such problem 
is incompatibility between devices in the home AV system. 
CE devices from one manufacturer often couple with an AV 
system in a different manner than similar devices from 
another manufacturer. For example, a tuner made by one 
manufacturer may not properly couple with a TV made by 
another manufacturer. 

[0005] In addition, where one device is much newer than 
another device additional incompatibilities may exist. For 
example, a new device might incorporate hardware (e.g., 
specific inputs and outputs) which enables more sophisti- 



cated remote control functions. This hardware may be 
unusable with older devices within the system. As another 
example, older tuners may lack suitable inputs for some 
newer devices (e.g., mini-disc players, VCR's, etc.), or may 
lack enough inputs for all devices of the system, 

[0006] Another problem is the lack of functional support 
for differing devices within the home AV system. For 
example, even though a TV may support advanced sound 
formats (e.g., surround sound, stereo, etc.), if an older less 
capable tuner does not support such functionality, the ben- 
efits of the advanced sound formats can be lost. 

[0007] Yet another problem is the proliferation of controls 
for the new and differing devices within the home AV 
system. For example, similar devices fi"om different manu- 
facturers can each have different control buttons and control 
switch formats for accomplishing similar tasks (e.g., setting 
the clock on a VCR, programming a VCR to record a 
program, and the like). In addition, each new device coupled 
with the AV system often leads to another dedicated remote 
control unit for the user to keep track of and learn to operate. 

[0008] Standards have been developed for the home AV 
system which aim to correct the interoperability and func- 
tionality problems of the conventional system. These stan- 
dards include the Home AudioA^ideo Interoperability 
(HAVi) Architecture and the Video Electronics Standards 
Association (VESA) Home Network, or VHN. 

SUMMARY OF THE INVENTION 

[0009] In an embodiment of a method according to the 
present invention, interoperability is facDitated between two 
networks. The method comprises: providing a VHN network 
having a VHN element; providing a HA\^ network having 
a HAVi element; translating messages via a protocol trans- 
lator coupled with the VHN network and the HAVi network; 
wherein interoperability is facilitated between the ILW 
element and the VHN element 

[0010] In an embodiment of a method according to the 
present invention, interoperability is facilitated between two 
networks. The method comprises: providing a VHN network 
having a VHN element; providing a HAVi network having 
a HAVi element; providing a protocol translator coupled 
with the VHN network and the HAVi network; and control- 
ling the at least one VHN element with the at least one HAM 
element. 

[0011] In an embodiment of a computer- readable media 
according to the present invention, interoperability is facili- 
tated between a VHN network having a VHN element and 
a HAVi network having a HAVi element. The computer- 
readable media comprises: providing instructions for cou- 
pling the VHN network with the HAVi network; and pro- 
viding instructions for facilitating interoperability between 
the HAVi element and the VHN element. 

[0012] In an embodiment of a system according to the 
present invention, interoperability is facilitated between two 
networks. The system comprises: a VHN network having a 
VHN element; a HAVi network having a HAVi element; and 
a protocol translator coupled with the VHN network and the 
HAVi network; wherein the protocol translator facilitates 
interoperability between the HAVi element and the VHN 
element. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

[0013] FIG. 1 is an illustratioa of a computer system 
suitable for use with the present invention. 

[0014] FIG. 2 shows subsystems in the computer system 
of FIG. 1. 

[0015] FIG. 3 depicts the arrangement of software ele- 
ments on a HAVi FAV device. 

[0016] FIG. 4 is a basic VHN device-to-device control 
model. 

[0017] FIG. 5 illustrates a VHN network coupled with a 
HAVi network. 

[0018] FIG. 6 illustrates FIG. 5 in greater detail. 

[0019] FIG. 7 is a flow diagram of a new device being 
plugged into a HAVi network. 

[0020] FIG. 8 is a flow diagram of a VHN appUcation 
controlling a HA\^ device. 

[0021] FIG. 9 is a flow diagram of a VHN application 
controlling a HAVi application, 

[0022] FIG. 10 is a flow diagram of a VHN device 
controlling a HAVi device. FIG. 10 is also a flow diagram 
of a VHN device controlling a HA\^ application, 

[0023] FIG. 11 is a flow diagram of a HAVi application 
controlling a VHN device. 

[0024] FIG. 12 is a flow diagram of a HAVi application 
controlling a VHN application. 

[0025] FIG. 13 is a flow diagram of a HAVi device 
controlling a VHN device. 

[0026] FIG. 14 is a flow diagram of a HAM device 
controlling a VHN application, 

DESCRIPTION OF THE SPECIFIC 
EMBODIMENTS 

[0027] As shown in the exemplary drawings wherein like 
reference numerals indicate like or corresponding elements 
among the figures, an embodiment of a system according to 
the present invention will now be described in detafl. The 
description describes an exemplary apparatus suitable to 
implement an embodiment of the present invention. Meth- 
ods of operation and associated user interface details in 
accordance with the invention are also provided. 

[0028] FIG. 1 shows a computer system 100 suitable for 
use to provide a system in accordance with the present 
invention. The computer system 100 includes a display 102 
having a display screen 104 (the display may be a digital 
television (DTV) or personal digital assistant (PDA)-like 
device, etc.), A cabinet 106 houses standard computer com- 
ponents (not shown) such as a disk drive, CD-ROM drive, 
display adapter, network card, random access memory 
(RAM), central processing unit (CPU) and other compo- 
nents, subsystems and devices (since these inventions talk 
about a home network, 106 may be a STB (set top box) and 
not a standard PC). User input devices such as a mouse 108 
having buttons 110, and a keyboard 112 are shown (another 
input device may be a two-way remote controller, a PDA- 
like device or a Sony Airboard device). Other user input 
devices such as a trackball, touch-screen, digitizing tablet. 



etc., can be used. In general, the computer system 100 is 
illustrative of one type of computer system, such as a 
desktop computer, suitable for use with the present inven- 
tion. Computers can be configured with many different 
hardware components and can be made in many dimensions 
and styles (e.g., laptop, palmtop, server, workstation and 
mainframe). Thus, any hardware platform suitable for per- 
forming the processing described herein is suitable for use 
with the present invention. 

[0029] FIG. 2 iUustrates subsystems found in the com- 
puter system 100. Subsystems within box 106 are directly 
interfaced to an internal bus 210, The subsystems include 
input/output (I/O) controller 212, system random access 
memory (RAM) 214, central processing unit (CPU) 216, 
display adapter 218, serial port 220, fixed disk 222, network 
interface adapter 224 and transceiver 230. The use of the bus 
aUows each of the subsystems to transfer data among the 
subsystems and, most importantly, with the CPU. External 
devices can communicate with the CPU or other subsystems 
via the bus by interfacing with a subsystem on the bus. The 
monitor 104 connects to the bus through the display adapter 
218. A relative pointing device (RPD) such as a mouse 108 
connects through the serial port. Some devices such as 
keyboard 112 can communicate with the CPU by direct 
means without using the main data bus as, for example, via 
an interrupt controUer and associated registers (not shown). 
The transceiver 230 can be coupled with a satellite system, 
cable system, telephone lines or any other system suitable 
for propagating information. The transceiver can include or 
be coupled with a communication interface, which can be 
coupled with bus 210. 

[0030] FIG. 2 is illustrative of one suitable configuration 
for providing a system in accordance with the present 
invention. Subsystems, components or devices other than 
those shown in FIG. 2 can be added without deviating from 
the scope of the invention. A suitable computer system can 
also be achieved without using all of the subsystems shown 
in FIG. 2. Other subsystems such as a CD-ROM drive, 
graphics accelerator, etc., can be included in the configura- 
tion without affecting the performance of the system 
included in the present invention. 

[0031] The invention is related to the use of apparatus, 
such as the computer system 100, for implementing a 
scalable pay-by-time technique for the secure multicast 
distribution of streaming content, including, but not limited 
to, video and audio. According to one embodiment of the 
invention, multicast distribution is provided by the computer 
system 100 in response to the processor 216 executing one 
or more sequences of one or more instructions contained in 
the system memory 214. Such instructions may be read into 
memory 214 firom a computer-readable medium, such as a 
fixed disk 222. Execution of the sequences of instructions 
contained in the memory 214 causes the processor to per- 
form the process steps described herein. One or more 
processors in a multi-processing arrangement may also be 
employed to execute the sequences of instructions contained 
in the memory. In alternative embodiments, hard-wired 
circuitry may be used in place of or in combination with 
software instructions to implement the invention. Thus, 
embodiments of the invention are not limited to any specific 
combination of hardware circuitry and software. 

[0032] The terms "computer-readable medium" and 
"computer-readable media" as used herein refer to any 
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(AVOS) 102 is a portability layer on top of the vendor- 
specific platform 104 (e.g., RTOS or Windows CE). The 
AVOS acts as a portability layer by allowing a change of 
vendor platform without the need to rewrite the upper layer 
applications 106 and middleware 108. Below the vendor- 
specific platform lie the 1394 device drivers 110 and other 
device drivers 112. 

[0041] When an application in a HAVi environment wants 
to find out about what kind of network devices or network 
services are available, the application goes to the registry 
114. Software elements describe themselves to the registry. 
Applications can go to the registry to find out what those 
software elements are. It is a way to implement discovery. 
The stream manager 116 is responsible for setting up 
streams of data. For example, the stream manager may 
stream video from a hard disc drive to a TV. 

[0042] The resource manager 118 is responsible for sched- 
uling resources. For example, tells devices when to turn on 
or off, or to play loudly or softly. Basically, the function of 
a resource manager is analogous to that of a conductor of a 
symphony. The event manager 120 acts as an event mecha- 
nism. An application may be interested in when an asyn- 
chronous event occurs. The event manager generates an 
event at appropriate times (e.g., when a TV turns on or off)- 

[0043] The messaging system 122 is a conduit for mes- 
sages to be passed through. The messaging system commu- 
nicates with the event manager 120, the stream manager 116 
and device control modules (DCM's) 124. DCM*s are 
conceptually central to the HAVi architecture and the source 
of flexibility in accommodating new features and devices, 
DCM*s act as software proxies. There is one DCM present 
in a HAVi system per device. In order to communicate with 
a given device, an application or other device communicates 
with the DCM, which in turn communicates with the given 
device using the appropriate protocol proprietary to the 
given device. 

[0044] The DCM manager 126 is responsible for loading, 
instantiating and removing DCM*s 124 from the system. 
The DCM manager oversees the installation and removal of 
DCM's. For, example, if a system included a TV, a hard 
drive and two set-top boxes, the DCM manager would 
determine on which the devices the various DCM's would 
run. The DCM manager would load the byte code from the 
configuration ROM of the BAV devices and create DCM's 
within one or both of the set-top boxes. There would only be 
one DCM created per device that is going to be controlled. 
The DCM manager oversees the DCM installation and 
makes sure that only one DCM is running per device that is 
going to be controlled. The DCM manager decides which 
FAV or lAV device stores each DCM. 

[0045] Intermediate AV devices (lAV's) and Base AV 
devices (BAV's) are also part of a typical HAVi system. lAV 
devices are generally lower in cost than FAV devices and 
more limited in resources. lAV devices do not provide a 
nmtime environment for Java bytecode and so cannot act as 
controllers for arbitrary devices within the home network. 
However, an lAV may provide native support for control of 
particular devices on the home network. 

[0046] A BAV device is a "dumb" device (e.g., a printer) 
that provides uploadable Java bytecode, but does not host 
any of the software elements of the HAVi architecture. The 



control information for the BAV device is stored on con- 
figuration read-only memory (ROM) within the device. This 
information relates to how to control the BAV device and 
how it talks to other BAV devices can be controlled by an 
FAV device via the uploadable bytecode or from an lAV 
device via native code. The protocol between the BAV 
device and the BAV software proxy may or may not be 
proprietary, Commimication between an FAV or lAV device 
and a BAV device requires that HAM commands be trans- 
lated to and from the command protocol used by the BAV 
device. 

[0047] A device (e.g., TV, camera, set-top box, stereo 
system, MP3 player) can be controlled (e.g., turn on, turn 
off, play, fast-forward) by commands. Those commands can 
be in Java bytecode, which can live inside the configuration 
ROM of the device itself. The DCM manager 126 reads the 
byte code in the configuration ROM of a BAV device and 
creates the DCM for the BAV device. When an entity tells 
the DCM to, say, power on, the DCM tells the corresponding 
device to power on. The DCM sends a control sequence (a 
command packet) over an IEEE 1394 bus, wireless connec- 
tion, etc, 

[0048] The function of the 1394 communication media 
manager (CMM) 128 is to manage communications and put 
the bits on the wires. In use, when a CE device is plugged 
into the HA\^ network, the network creates a bus reset and 
sends this signal on the 1394 bus to all devices on the bus. 
The CMM detects the bus reset and sends a new CE device 
event to the DCM manager 126. This happens through the 
event manager 120. Any device can register with the event 
manager and will subsequently be informed when a new 
device is on the bus. The CMM then reads the configuration 
ROM and retrieves a DCM code unit. The CMM causes the 
code unit to install the DCM 124. Subsequently, the DCM 
124 registers with the messaging system 122 and the registry 
114, 

[0049] A HAVi application 106 that has initialized itself 
and is running registers with the messaging system 122 so 
that it can communicate with other processes. The event 
manager 120 notifies a HAM application that is running of 
a new device on the bus. The HAVi appUcation can go to the 
registry 114 to find out if there is a device that it wants to 
control (e.g., VCR, TV, etc.). Let us assume the application 
is looking for a VCR to control. The application may find the 
VCR and gets the software handle from the registry. The 
application is now able to commimicate with the DCM for 
the VCR, The HAVi application module can talk to the 
resource manager 118 and give instructions to, for example, 
turn on the VCR at 10:00 p.m. and record. 

[0050] Furthermore, the DCM manager 126 is notified by 
the event manager 120 that there is a new device on the bus. 
The DCM manager reads the profile in the configuration 
ROM and reads the self-describing data (SDD) to find out 
what the device is. The DCM manager decides on a DCM 
host for the DCM of the new device and then loads the 
DCM. The HAM application 106 may do discovery and go 
into the registry 114 and discover the new DCM was loaded. 
The HAVi application may then decide to control the new 
device (e.g., set the clock on the device, the device being a 
VCR). 

[0051] The VHN architecture, mentioned above, allows 
for the recognition and interoperability of multiple home 
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network devices. This interoperability enables consumers to 
access all their networked appliances through devices such 
as their PC or TV, VHN utilizes Internet technologies to 
seamlessly connect all home devices, while providing 
remote device control using any Web browser. Using Inter- 
net protocols, the VHN network provides the capability to 
couple different network technologies together under one 
completely supported system. 

[0052] A graphical user interface (GUI) for a VHN system 
may consist of a plurality of icons displayed on a computer 
or TV screen. When a user selects an icon, the HTML pages 
are retrieved from the configuration ROM of the device in 
question. The HTML pages are displayed for the user. This 
allows the user to control the given device. 

[0053] Referring to FIG. 4, a basic VHN device-to-device 
control model is shown. The figxire shows a controller 
module 400 and a controlled module 402. The controller 
module can discover the controlled module and control the 
services 404 of the controlled module. The controlled apph- 
cation component 406, an embedded executable software in 
the controlled module, has direct control over the services. 
The controlled module application interface 408 describes 
the controllable services and interface of the controlled 
application component. 

[0054] If a device-to-device control process is triggered, 
the controller module 400 will first attempt to discover the 
controlled module 402, After the controller module has 
discovered the interface of the controlled module, it can send 
commands thereto. This generates an acknowledgment and/ 
or machine action of the services 404. VHN allows the use 
of Web technology (XML) for the message and interface 
formats. A home network broker and interface repository 
(HNB & IR) can be located in any third device, or in a 
separate, dedicated device. The HNB & IR is a software 
agent that helps one device discover other devices and what 
their commands are, among other things. 

[0055] When a device first comes online it registers with 
the HNB & IR, revealing the type of device it is and the 
commands that the device supports. If the controller module 
400 wants to control the controlled module 402, the con- 
troller module first has to go through discovery. Therefore, 
the controller module reads the HNB & IR and discovers the 
controlled module (e,g., that of a VCR) and also the com- 
mands it needs to communicate with or control the VCR. 
The controller module obtains the handle (IP address) for the 
controlled module. The controller module can now talk to 
the VCR and send commands through an XML-based 
remote procedure call (RPC). 

[0056] In accordance with embodiments of the present 
invention, FIG. 5 illustrates a network 500 comprising a 
VHN network 502 and a HAVi network 504. The VHN 
network and the HAVi network each comprise at least one 
element. The elements can include devices and application. 
Interoperability is facilitated between the VHN network and 
the HAVi network by providing a protocol translator 506 
coupled with the VHN network and the HAVi network, all 
of which are coupled to an IEEE 1394 bus 508 or other 
suitable bus. The protocol translator 506 can physically or 
logically be on the some device as the HAVi controller 504. 
The protocol translator, or bridge, allows for controlling a 
HAVi element (device or application) with a VHN element 
(device or application). 



[0057] Turning now to FIG. 6, FIG. 5 is shown in greater 
detail. A VHN bridge control manager (VBCM) 600, does 
handshaking and protocol conversion between the HAVi and 
VHN networks. The HAVi bridge control manager (HBCM) 
602, talks to the HNB & IR 604 in behalf of the HAVi 
network. The HBCM 602 and the VBCM 600 together 
comprise the protocol translator 506, converting HA\^ mes- 
sages into XML messages and converting XML messaging 
into HAVi messages (as well as other things). The HAVi- 
VHN DCM*s 610, 618 (described below) may or may not be 
considered a part of the protocol translator. The HNB & IR 
knows which devices are on the VHN network and the HAVi 
network providing the VBCM is fully operational. Likewise, 
the HA\^ registry knows which devices are on the HAVi 
network and the VHN network providing the HBCM is fully 
operational. In order for this to happen it is up to individual 
VHN devices to inform the HNB & IR of its presence in the 
VHN network and individual HAVi devices to inform the 
HAVi registry of its presence in the HAVi network. Other- 
wise the HNB & IR and HAVi registry will not know when 
devices come, go and change state. The HBCM constantly 
monitors the HNB & IR for new VHN devices so that the 
HAVi network 504 can know when to instantiate the respec- 
tive HAVi- VHN DCM and it can register the VHN device 
with the HAVi registry. If a VHN device is removed from the 
network, the HBCM will notify the VBCM which will in 
turn remove the respective HAVi- VHN DCM. This is done 
to free memory, 

[0058] As shown in FIG. 7, when a new device, such as 
hard disc drive (HDD) 606 or DVD player 608, comes on the 
HAVi network 504 (step S700), a bus reset is generated. At 
S702, the DCM manager loads the HAVi DCM, and the 
DCM instantiates itself. At S704, the DCM (and correspond- 
ing FCMs) registers with the HA\^ messaging system and 
the registry 114. At S706, the HAVi event manager 120 
notifies the VBCM 600 of the event (the new DCM), At 
S708, the VBCM instantiates the HAVi- VHN device DCM 
and sends a message to the HBCM 602, The HBCM 
configures the new HAVi device into the VHN network and 
returns an IP address to the VBCM (the IP address will be 
used to reference the HAVi device in the VHN network). The 
returning of the IP address signifies that the HBCM suc- 
cessful configured the HAM device in the VHN network. 
The VBCM uses the IP address in the protocol conversion 
and passes it to the HAVi-VHN device DCM. 

[0059] Turning to FIG. 8, at step S800, after a DVD 608 
is connected, a user from the VHN network can access the 
HAVi DVD device. This discover occurs by accessing the 
HNB & IR 604. Control of the DVD player is through the 
VHN application's Web browser 615 and accessing the 
VHN BCM, and the device application 617. The Web client 
pulls the HTML page out and HAVi-VHN DCM, thereby 
allowing the user to control the DVD player. At step S802, 
the user selects a "play*' icon on the DTV 616. At step S804, 
the play command is encoded in XML and sent to the 
VBCM 600. At step S806, the VBCM in turns sends an 
HTML/XML command to the respective HAVi-VHN DVD 
DCM 618. HAVi does not know how to interpret XML or 
HTML as HAVi does not use these protocols. The HAVi- 
VHN DVD DCM 618 knows the HAVi protocols as well as 
the VHN protocols. 

[0060] At step S808, the HAVi-VHN DVD DCM 618 
encodes the XML commands from the VHN network into a 
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HAVi messages because the HAVi DVD DCM 621 only 
knows HAVi messaging. Therefore, the VHN protocol has 
been mapped into IlAV^ messaging that the HAVi DVD 
DCM imderstands. The DVD player can thus be controlled 
by the HAVi DVD DCM. Consequently, we have a VHN 
application on the VHN network 502 controlling a HAVi 
device. 

HAVi Startup Process 

[0061] Before a HAVi application or device can become 
"HAVi aware/' it must go through the HA\^ startup process. 
In part, this means the application or device registers with 
the HAVi messaging system to obtain a software element 
identification (SEID) which is a globally unique identifica- 
tion in the HAVi network. The SEID is used in the HAVi 
system to allow other HAVi or VHN processes to access the 
application or device. Next the application or device must 
describe itself to the HAM registry 114. Afterwards the 
application is free to use any HA\^ services. This same 
process must be followed for VHN devices or applications 
that want to interface to the HAVi network. This means VHN 
processes wishing to operate in the HAVi network must 
obtain a valid SEID and register with the HAM registry. 

The VHN Bridge Control Manager (VBCM) 

[0062] The main function of the VBCM 600 is to expose 
HAVi devices to the VHN network and VHN devices to the 
HAVi network 504. When the VBCM first initializes, it 
registers with the HAM event manager 120 and request that 
all events related to new/gone device/application. When the 
VBCM receives notice (an event) of new devices or appli- 
cations (an asynchronous event), it queries the HAVi registry 
114 to determine their services. When the VBCM finds a 
HAVi device or application it creates a HAVi- VHN DCM. 
The VBCM indirectly gets an IP address (using VHN's 
DHCP services) and assignes it to the HAVi- VHN DCM 
(getting the IP address is actually done by the HBCM). This 
is so the HAVi-VHN DCM's can send and receive XML 
messages to the VHN network. The HAVi- VHN DCM's 
may contain HTML pages to represent the devices' services. 
If so, the HTML pages can be downloaded firom the World 
Wide Web (WWW) or contained in the devices configura- 
tion ROM, or from other resources (e.g., a diskette or 
memory card that ships with device, etc). 

[0063] After a HAVi- VHN DCM is created, the VBCM 
sends an XML message to the HAVi BCM notifying it of a 
new HAVi device or application. The XML message to the 
HAVi BCM is descriptive information about the HAVi 
device or application (model, device type, device manufac- 
turer, etc.) and a unique identifier (SEID). This information 
will be used by the HAVi BCM to register HAM devices or 
applications in the VHN network. When the HAM BCM 
successfully configures the HAM device, it returns an IP 
address to the VBCM. The IP address is used to reference the 
HAVi device in the VHN network. Lastly, the VBCM passes 
the IP address to the HAVI-VHN DCM where it will be used 
to cross reference HAVi messages and XML messages. 
Without this process, HAM devices or applications would 
not be discovered in a VHN network. 

[0064] Likewise, when the new VHN devices or applica- 
tions are detected by the HAVi BCM, the VBCM 600 will 
receive a message from the HBCM. It is the responsibility 
of the VBCM to register the VHN device or application with 
the HAM messaging system and registry. In turn, a SEID 
value is generated for the VHN device or application. The 



SEID is used to register the VHN device or application with 
the HAM registry 114. The registry will be given suflScient 
information about the VHN device or application so that the 
VHN device or application can be discovered in a HAM 
network. 

[0065] Finally, a HAVi-VHN DCM is created for the VHN 
device or apphcation. This is necessary for VHN devices or 
applications to communicate with HAVi devices and for 
HAVi devices (or application) to communicate with VHN 
device. The HAM- VHN DCM will translate XML messages 
into HAM messages and HAVi messages into XML mes- 
sages. Without this process, VHN devices or applications 
would not be discovered in a HAVi network. 

[0066] A final note about the VBCM that needs to be 
pointed out is that it must support all the VHN Internet 
protocols which make it possible to interface into the VHN 
network. This means it will support TCP/IP and Web pro- 
tocols. It will use the IP over IEEE 1394 protocol to send and 
receive XML messages to/from the VHN network. Also, it 
will contain a web server that is able to send HTML pages 
to VHN processes. Likewise, it will contain a modified web 
browser that is able to receive HTML pages and translate 
them into HAVi messages, Java UI (AWT), or DDI objects. 
In some situation, it is possible the HAVi-VHN DCMs may 
contain these and other protocols. This will allow the DCM 
to interface directly with the VHN devices without the aid of 
the HBCM and VBCM. However, in order to keep the 
system light (use less memory) it is desirable to keep the 
VHN protocols in the VBCM and have the HAVI-VHN 
DCM*s tise the services of the VBCM as needed. 

The HAM Bridge Control Manager (HBCM) 

[0067] When the HBCM 602 is notified of a new HAM 
device (or application) by the VHN BCM, it creates an IP 
address for the device using an available DHCP server. A 
map between the IP address and the SEID are maintained by 
the HBCM and VBCM independently of one another. This 
is used to cross-reference a HAM device when it is being 
referenced in the VHN network as well as a VHN device 
when it is being used in the HAM network. 

[0068] When the HAVi BCM is notified of a new HAM 
application or device, it registers the information with the 
HNB & IR 604. This means passing an XML message that 
contains the IP address (and possibly the SEID) and a 
description of the HAVi device or application to the HNB & 
IR. Some of the device or application descriptive informa- 
tion may contain basic information, such as the device 
model, device features and a user-configurable device name. 
Other device manufacture-specific information may be 
included with the device information (i.e., device features, 
device software version, etc.). Without this process, a HAVi 
device or application would not be discovered in a VHN 
network. 

[0069] ITie HBCM 602 is responsible for notifying the 
HAVi system of VHN processes (new and gone). This is 
accomplished by the HAVi BCM's ability to detect IEEE 
1394 bus resets that helps it detect new VHN devices. Once 
a bus reset is detected, the HAVi BCM queries the HNB & 
IR 604 to discover new/gone VHN devices. In some situa- 
tions VHN devices will not operate on the IEEE 1394 
networks. In this case the HAVi BCM cannot dynamically 
detect VHN devices (or applications), so it is must periodi- 
cally poll the HNB & IR to discover new/gone devices. 
There may be special situations where the HAM BCM has 
to interface into VHN Backbone Component Interface (BCI) 
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devices to obtain end device information or state conditions. 
These situations would occur when end device or BCI 
devices are unable to report to the HNB & IR. 

[0070] Once the HAVi BCM discovers a new VHN device 
(either by the HNB & IR or a BCI device), it will send a 
XML message to the VHN BCM requesting the VHN 
devices be configured and registered in the HAVi system. 
This will result in the VHN BCM registering the VHN 
device with the HAVi messaging system and returning a 
HAVi SEID. Also, the VHN BCM will register the VHN 
device with the HAVi registry 114 and create a HAVi-VHN 
DCM. This will allow HAVi applications and devices to 
interface into the VHN network 502. The HAVi-VHN DCM 
will communicate to the VHN network over XML and RPC. 
When the configuration process is successful, the VHN 
BCM wiU send the SEID of the VHN device to the HAVi 
BCM signifying the registration process was completed. 
Without this process, a VHN device or application would not 
be discovered or operate in a HAVi network. 

[0071] In one embodiment, as shown in FIG. 9, a VHN 
application can control a HAVi application. The VHN appli- 
cation queries the HNB & IR 604 to discover a HAVi 
application 106, at S900 and S902. The HNB & IR will 
return the IP address (and possible the SEID) of the HAVi 
application. When the VHN application sends an XML RPC 
to the HAVi application, at S904, it will be picked up by the 
HAVi VHN BCM (HAVi-VHN DCM). In turn, the VHN 
XML message will be translated into a HAM message using 
the SEID of the HAVi application, at S906. Furthermore, the 
VHN BCM (via the HAVi-VHN DCM) sends the HAVi 
message to the HAVi application, at S908. 

[0072] When the HAVi application 106 responds back to 
the VHN application, it does so using the VHN SEID 
address that was encoded into the HAVi message. The VHN 
BCM translates (via the HAVi-VHN DCM) the HAVi mes- 
sage into a XML RPC response using the assigned IP 
address of the VHN application. 

[0073] Likewise, referring to FIG. 10, a VHN device 616 
can control a HAM device. Similar to the example above, the 
VHN device 616 queries the HNB & IR 604 for HAVi 
devices, at SIOOO. What is returned from the HNB & IR is 
the IP address (and possibly the SI ED) of the HAVi device. 
The VHN device is free to send XML messages (using the 
assigned IP address of the HAVi device) to the VHN BCM 
(via the HAVi-VHN DCM), at S1002. The VHN BCM 
recognizes the IP address of the VHN device 616 and 
reformats the XML message into a HAM message that will 
be sent to the HAVi DCM (via the HAViVHN DCM), at 
S1004. 

[0074] The response from the device's HAVi DCM will 
send a HAVi message to the VHN BCM (HAVi-VHN DCM) 
using its mapped SEID address, at S1006. This will cause 
the VHN BCM to translate the HAVi message into a XML 
message that will be sent to the VHN device, at S1008. The 
SEID and IP address of the devices will t»e used to cross- 
reference each device (VHN and HAVi), 

[0075] Similarly, a VHN device 616 can control a HAVi 
application 106. The only difference between this case and 
the one above is that the VHN device uses the HAVi 
application IP address which is obtained from the HNB & 
IR. The VHN BCM wiU translate the IP address of the HAVi 
application into the respective SEID. Everything else is the 
same, and is shown in FIG. 10. 

[0076] Still referring to FIG. 6, in other embodiments 
according to the present invention, the HAM application 106 



can control a device (e.g., the DTV 616) on the VHN 
network 502. Referring to FIG. 11, as shown in steps SHOO 
and S1102, when the VBCM 600 discovers that there is a 
DTV on the VHN network, it creates the VHN DCM 622 
(HAM- VHN DCM). The VHN DCM can be considered to 
be a virtual DCM because the DTV physically resides on the 
VHN network and not the HAM network. 

[0077] Next, at step S1104, the VHN DCM 622 registers 
itself with the registry 114. At step S1106, the HAVi appli- 
cation 106, which is attempting to control a DTV, goes to the 
registry 114 and queries for all DTVs on the network. 
Subsequently, the HAVi application finds the DTV 616 
SEID which enables it to conU-ol the DTV*s respective 
DCM. The HAVi application does not have information that 
the DTV 616 is a VHN device. 

[0078] At step S1108, the HAM application 106 can now 
control the DTV 616 (e.g., turn it on or off, set the time, etc.) 
by sending commands to the VHN DCM 622 via HAM 
messaging. The HAVi application thinks that it is talking to 
a HAVi DCM 124, using the HAVi protocols. Furthermore, 
any of the HAM software modules that communicate with 
the VHN DCM 622 do so through HAVi messaging. 

[0079] At step SlllO, the VHN DCM 622 can now 
communicate with the VBCM 600 via XML and HTML. At 
step, S1112, the VBCM, in turn, communicates with the 
HBCM 602 in XML. The HBCM 602 thus controls the DTV 
616, as shown in step S1114. The result is a HAVi applica- 
tion 106 running on a HAVi network 504 controlling a VHN 
device 616. In some situation, it the VHN DCM (HAVi- 
VHN DCM) can interface directly with the client applica- 
tion. This is done if the VHN DCM contains the IP protocols 
and web protocols. In this case, the VHN DCM using the IP 
over IEEE 1394 protocols to communicate with the VHN 
device. 

[0080] In an alternate embodiment, referring to FIG. 12, 
a HAVi application 106 can control a VHN application. A 
HAVi application queries the HAM registry for VHN appli- 
cations (an SEID of the VHN application is returned), at 
S1200. Once the HAVi application obtains the SEID of the 
VHN application, it is free to send HAVi messages to the 
VHN application. The HAM- VHN DCM translates the 
HAVi message to XML messages, at S1202 and S1204. The 
SEID of the VHN application is used to retrieve the VHN 
applications IP address. The XML message is transmitted 
using IP/1394. 

[0081] The VHN application uses the IP address of the 
HAVi application when it sends a response. The VHN BCM 
(via the HAVi-VHN DCM) translates the XML message into 
a HAVi message and sends it to the HAVi application, at 
S1206. 

[0082] Moreover, a HAVi device can control a VHN 
device 616, as illustrated in FIG. 13. A HAVi device is able 
to control a VHN device by going to the HAVi registry 114 
and getting the SEID of the VHN device. The HAM device 
sends a message to the VHN device (via HAVi messaging), 
at S1300. The VHN device's HAVi-VHN DCM is able to 
receive the HAVi message and translate it into a XML 
message, at S1302. It maps the SEID address into the VHN 
devices IP address. When the VHN device 616 responds to 
the HAVi device it does so by sending an XML response, at 
S1304. The VHN BCM (via the HAM- VHN DCM) trans- 
lates the XML message into a HAM message and sends it to 
the HAVi DCM, at S1306 and S1308. 

[0083] In another embodiment, as shown in FIG. 14, a 
HAVi device can control a VHN application. A HAVi device 
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can control a VHN device by getting its SEID from the HAVi 
registry 114 and sending it messages, at SI 400. The HAVi 
device's DCM sends HAVi messages to the HAVi- VHN 
DCM which in turn sends XML messages to the VBCM, at 
S1402. The VBCM in turns sends XML messages to the 
VHN application, at S1404. When it comes time for the 
VHN application to respond to the HAM device, it will send 
XML messages (using the IP address of the HAVi device) 
back to the VBCM. At this point, the message will be parsed 
and passed back to the HAVi- VHN DCM. The HAVi-DCM 
will reformat the VHN message into HA\^ messages and 
pass them on to the HAVi DCM. At this point the HAVi 
DCM can send proprietary commands (i.e., AV/C com- 
mands) to the HAVi device. 

[0084] The above description is illustrative and not restric- 
tive. Many variations of the invention will become apparent 
to those of skill in the art upon review of this disclosure. The 
scope of the invention should, therefore, be determined not 
with reference to the above description, but instead should 
be determined with reference to the appended claims along 
with their full scope of equivalents. 

What is claimed is: 

1. A method of facilitating interoperability between two 
networks, the method comprising: 

providing a VHN network having a VHN element; 

providing a HAVi network having a HAVi element; and 

translating messages via a protocol translator coupled 
with the VHN network and the HAVi network; 

wherein the interoperability is facilitated between the 
HAVi element and the VHN element. 

2. The method of claim 1, wherein the protocol translator 
comprises: 

a HAVi bridge control manager; 

a VHN bridge control manager coupled with the HAVi 
bridge control manager; and 

a HAVi- VHN DCM coupled with the VHN bridge control 
manager. 

3. A method of facihtating interoperability between two 
networks, the method comprising: 

providing a VHN network having a VHN element; 

providing a HAVi network having a HAVi element; 

providing a protocol translator coupled with the VHN 
network and the HAVi network; and 

controlling the HA\^ element with the VHN element. 

4. The method of claim 3, wherein the protocol translator 
comprises: 

a HAVi bridge control manager; 

a VHN bridge control manager coupled with the HAVi 
bridge control manager; and 

a HAVi- VHN DCM coupled with the VHN bridge control 
manager. 

5. A method of facilitating interoperability between two 
networks, the method comprising: 

providing a VHN network having a VHN element; 



providing a HA\^ network having a HAVi element; 

providing a protocol translator coupled with the VHN 
network and the HAVi network; and 

controlling the VHN element with the HAV^ element. 

6. The method of claim 5, wherein the protocol translator 
comprises: 

a UASTi bridge control manager; 

a VHN bridge control manager coupled with the HAVi 
bridge control manager; and 

a HAVi- VHN DCM coupled with the VHN bridge control 
manager. 

7. The method of claim 5, wherein controlling comprises 
controlling a HAVi device with a VHN device. 

8. The method of claim 5, wherein controlling comprises 
controlling a HAVi device with a VHN apphcation. 

9. The method of claim 5, wherein controlling comprises 
controlling a HAVi application with a VHN device. 

10. The method of claim 5, wherein controlling comprises 
controlling a HAVi application with a VHN application. 

11. A computer-readable media for facihtating interoper- 
ability between a VHN network having a VHN element and 
a HAVi network having a HAVi element, the computer- 
readable media comprising: 

providing instructions for coupling the VHN network 
with the HAVi network; and 

providing instructions for facilitating interoperability 
between the HAVi element and the VHN element. 

12. The computer-read able media of claim 1, wherein 
providing instructions for facilitating interoperability com- 
prises: 

providing instructions for a HAM bridge control manager; 

providing instructions for a VHN bridge control manager 
coupled with the HAVi bridge control manager; and 

providing instructions for a HAM- VHN DCM coupled 
with the VHN bridge control manager. 

13. A system for facilitating interoperability between two 
networks, the system comprising: 

a VHN network having a VHN element; 

a HAM network having a HAVi element; and 

a protocol translator coupled with the VHN network and 
the HAVi network; 

wherein the protocol translator facilitates interoperability 
between the HAVi element and the VHN element, 

14. The system of claim 13, wherein the protocol trans- 
lator comprises: 

a HAM bridge control manager; 

a VHN bridge control manager coupled with the HAM 
bridge control manager; and 

a HAM- VHN DCM coupled with the VHN bridge control 
manager. 

♦ ♦ * ♦ » 
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